Historically, package types were defined in combination by the content source plugins and agent plugins - for each resource type (defined by the agent plugins) there could be a list of package types that that resource type accepted (again this is defined by the agent plugin). The content source plugins then declared what package types for what resource types they provide and these two were matched together to provide correct data for correct resource types.
With the introduction of the serverside CLI scripts, we needed to break the connection between a package type and resource type in order to be able to store the scripts inside the repositories. But what then is going to define the package types? It can't be the agent plugins anymore because there is no concept of a CLI script on the agent (i.e. we have no resources of the CLI script that can be discovered and managed on the managed machines).
There were 2 possible solutions - just hardcode the CLI script as a special package type that automagically exists on the server, or to create a new type of serverside plugins that would be able to define the package types.
The good thing about the server plugin solution is that it is then possible to define additional runtime "behavior" of the package type by having a sort of package type "component" class that would provide for example validation methods, etc.
The package type plugins are defined using a plugin descriptor conforming to the package type plugin XSD accompanied by a "behavior" class that implements the package type behavior interface.
The behavior of the package currently isn't too powerful and provides hooks mainly focusing on the versioning of the packages (provides hints for the UI for the version string formatting and defines ordering of the versions). It also provides the plugin with the ability to modify the package details before they get persisted into the database. The reason for this is that the only use of the package type plugin is the CLI package type that needs to accomplish one thing that is quite "interesting" in the context of the current content subsystem design.
The content subsystem is basically one huge flat (i.e. not hierarchical) store of packages that are identified by their name, version, type and architecture. The repositories are then merely "views" into this flat store - a single package might appear in multiple repos or none. Packages originate from content sources or can be uploaded by users.
This is a potential problem for CLI scripts. Different users might want to upload a script called "test.js" into their repositories which they don't necessarily mutually see and therefore the second user to upload their "test.js" script in version 1.0 would be very surprised to find that such script already exists (i.e. a package of name "test.js" of the CLI package type with version 1.0 and no architecture). The solution to this provided by the package type behaviors is the ability to modify the package details (i.e. name, version, packagetype and architecture) before they get persisted.
Because of the problem described above, the CLI package type defines the version string as username:osgi_version. I.e. the version of each script a user uploads is going to be prepended by his/her username. This ensures that both users A and B are able to upload their "test.js" scripts in version 1.0 because the version is going to get transformed into A:1.0 and B:1.0 before it gets persisted.